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INTERNET SETTLEMENT SYSTEM 



This application isfc continuation-in-part of serial no. 08/727,996, filed on October 



9, 1996, which claims priority of provisional application no. 60/017,682, filed on May 21, 



The present invention relates to an accounting system used by Internet Service 
Providers (ISP) and more particularly to a system that tracks the amount of time a user is 
connected to the Internet through a system operated by a first ISP. A settlement operator 
receives this information and uses it to generate a report which is forwarded to a second ISP 
who is responsible for paying for the amount of time the user was connected to the Internet 
through the system operated by the first ISP. 



The use of the Internet has become such an important part of daily life that travelers 
like to be able to access the Internet when they are traveling. Typically, a person accesses 
the Internet through a company referred to as an Internet Service Provider (ISP). The user 
establishes an account with their home ISP and can then access the Internet by connecting 
to the ISP's Internet access system using a modem. The ISP bills the user for this service at 
some regular interval. 

A problem encountered by travelers is that when they are traveling, connecting to 
their home ISP frequently means placing a long distance call. Such a call is not only 
expensive, but it fails to take advantage of the benefits of the Internet. Frequently, 
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regardless of where the traveler is traveling, there are local ISP's in the area. However, in 
the past, since the traveler did not have an account with these ISP's, he or she could not log 
on to the Internet through these local ISP's. Recently, techniques have become available for 
allowing a traveler to use the system of a local ISP to connect to the Internet, even though 
5 the user does not have an account with the local ISP (this is referred to as Internet roaming). 
However, what is needed is a convenient system for allowing the fees incurred in this 
roaming process to be tracked and reported to the appropriate parties. 



SUMMARY OF THE PRESENT INVENTION 

1 0 Briefly, the present invention comprises a method and apparatus for tracking the 

amount of time a user is connected to the Internet through the system of a first Internet 
Service Provider with whom the user does not have an account. A first server is used to 
track the amount of time the user is connected to the Internet through the system of the first 
Internet Service Provider. 

1 5 A user record is transmitted from the first server to a central settlement server. The 

user record comprises data that at least includes an identifier for the first user and the 
amount of time the first user was connected to the Internet through the first system. In the 
preferred embodiment, a second server is used to store a plurality of user records before 
they are transmitted to the central settlement server. The central settlement server generates 

20 a report from the user record which, includes the amount of time the first user was 

connected to the Internet through the first system. The report is then provided to the first 
Internet Service Provider by mail, fax or over the Internet. Typically, the report will include 
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a listing of a plurality of users who have utilized the first Internet Service Provider's system. 
A similar report is also sent to a second Internet Service Provider with whom the user does 
have an account, so that the second Internet Service Provider can bill the user for his or her 
usage of the Internet. A combined report can be sent to each Internet Service Provider 
which offsets the credits and debits for the Internet Service Provider to show a net balance 
for the Internet Service Provider. 

The apparatus includes a first server that creates a record of the user's Internet usage 
and sends the record to a second server. The second server collects records from a plurality 
of Internet Service Providers and forwards the records to a third server (the central 
settlement server) on a regular basis. The third server processes the data in the plurality of 
records and generates a report showing how much money the first Internet Service Provider 
is owed for allowing the user to access the Internet through the system of the first Internet 
Service Provider. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic view of a system that utilizes a remote user authentication 

server; 

Fig. 2 is a block diagram of the software loaded on the remote user authentication 

server; 

Fig. 3 is a schematic view of a remote user authentication server connected to a 
home internet service provider server via the Internet; 
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Fig. 4 is a flow chart illustrating the method used to provide remote user access to 
the Internet; 

Fig. 5 is a schematic view of a system that utilizes a remote authentication server 
and a pouting server; 

Fig. 6 is a flow chart illustrating the method used by the routing server to verify that 
a home ISP is available for authenticating user information; 

Fig. 7 is a schematic diagram of a system for tracking usage information for users 
who access the Internet through a' remote internet service provider according to the present 
invention; 

Fig. 8 is a detail report generated according to the present invention; 
Fig. 9 is a summary report generated according to the present invention; 
Fig. 10 is an invoice report generated according to the present invention; 
Fig. 1 1 is a credit/debit settlement report generated according to the present 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Fig. 1 is a schematic diagram of a remote user network access system 10 comprised 
of a remote user authentication server 14, a modem rack 18, a communication server 22, 
and a remote computer 26. A remote computer 26 is connected to the modem rack 1 8 by a 
standard telephone link. The modem rack 18 is connected to the communication server 22 
(also referred to as a Network Access Server or NAS) which is connected to the remote user 
authentication server 14 by an Internet protocol (IP) addressable network 30, such as a local 
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area network (LAN) or a wide area network (WAN). A router 34 is also connected to the 
network 30 for routing communications to other IP addressable networks. The router 34 is 
a commercially available hardware system and provides a connection between the network 
30 and- the Internet. In this application, the term Internet refers to a global communications 
network. 

An optional customer billing module 38 can be connected to the network 30 for 
collecting user information for billing purposes. The billing module 38 comprises a server 
42 and a customer database 46. Typically, the module 38 is protected by a firewall 50 so as 
to inhibit unauthorized access to the billing module 38 

The remote computer 26 can be any type of computer equipped with a modem, such 
as a standard laptop computer. The modem rack 18 includes a plurality of modems so that a 
plurality of remote computers 26 can access the system 10. The communication server 22 
is a standard communication server that functions to connect the remote computer 26 to the 
network 30. 

The remote user authentication server 14 comprises a commercially available user 
authentication server that has been modified with novel software to perform the functions 
illustrated in Fig. 2. Commercially available servers that are suitable for this purpose 
include Radius type servers originally developed by Livingston Enterprises(Radius is an 
acronym for Remote Authentication Dial In User Service). Similarly, a TACACS+ 
protocol and a TACACS+ protocol server can also be used as the server 14 (TACACS+ is a 
general purpose customer authentication protocol available from Cisco Systems Inc.). 



AIMN-OI-6 
291/01 19671.01/1 



5 




Fig. 2 illustrates that the server 14 includes a plurality of software modules such as a 
user recognition module 54, a host table module 58 and a connection time log 62. The host 
table module 58 is a listing by domain name of Internet Service Providers who have an 
account with the local Internet Service Provider. The connection time log module 62 is a 
5 module that keeps track of the time a user is logged onto the Internet, typically for billing 
purposes, by recording log in and log out information. The user recognition module 54 is 
discussed in more detail with respect to Fig. 4 below. 

Fig. 3 illustrates a connection between a local system 63 (i.e. the local network of a 
local Internet Service Provider) and a home Internet Service Provider system 64 via an 

1 0 Internet connection 65. A router 66 transfers information sent by the router 34 from the 
Internet connection 65 to a home network 67, such as a LAN or WAN. A user 
authentication server 68 and an optional billing system 69 are connected to the network 67. 
Typically, a firewall 70 protects the billing system 69 from unauthorized access. The 
system 63 and 64 illustrate a peer-to-peer system because the authentication server 14 

1 5 knows the IP address of the server 68 without having to retrieve it from another server. 

Fig. 4 illustrates the functions performed by the user recognition module 54. In 
block 80, a user has used the remote computer 26 to connect to the modem rack 1 8 of a 
local Internet Service Provider. In the method of the present invention a user who is not a 
customer of the local Internet Service Provider logs in using the following format: a user 

20 identifier plus a home ISP identifier plus a password. For example, an acceptable login 
format might be of the form username@userdomain, where the term userdomain is the 
domain name of the user's home Internet Service Provider, and the term user name is the 
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user identification used with the user's home Internet Service Provider. For example, the 
login could bejdoe@aimnet.com, which is a typical e-mail address. Normally a password 
will also be used in the login process. 

* In block 84, the user recognition module 54 looks to see if the home ISP identifier, 
5 for example the term @userdomain, is in the login field. If it is, then in block 88, the home 
ISP identifier is checked against the host table 58 (shown in Fig. 2) to verify that the home 
ISP identifier (i.e. the user's home Internet Service Provider) is registered with the local 
Internet Service Provider. Block 92 illustrates that access to the Internet is denied if the 
home ISP identifier is not listed in the host table 58. If the home ISP identifier is listed in 

1 0 the host table 58, the server 14 routes the username (and password) to the home Internet 
Service Provider system 64 via the router 34, the Internet link 65 and the router 66. In 
block 96, the user authentication server 68 then verifies that the user is a customer of the 
home Internet Service Provider (e.g. has an account and is in good standing). If the server 
68 decides that the user is a customer of the home Internet Service Provider, then in block 

15 1 00, the server 68 sends an authorization message back to the local Internet Service 

Provider system 63, via the Internet connection 65. Alternatively, the server 68 can deny 
authorization as indicated at block 104. 

In block 84, if an identifier for the home ISP is not present, then the server 14 
checks to see if the user is a customer of the local ISP, and hence is authorized to use the 

20 system 63 at block 112. 

Fig. 5 illustrates an embodiment of the present invention referred to as a centralized 
remote Internet access system 120. The system 120 includes a dialer 124, a local network 
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access server 128, a local authentication server 132, a first routing server 136, a second 
routing server 138 and a home authentication server 140. The second routing server 138 is 
an optional component as is discussed below. Additionally, the server 136 includes a link 
to a domain name server 139. The domain name server 139 is a distributed database that 
provides the mapping between IP addresses and hostnames. 

The dialer 124 comprises commercially available communications software running 
on a first computer to be connected to a second computer via a modem connection. For 
example, communications software available in software programs such as Windows 95™, 
Netscape Navigator™ or Chameleon™ can function as the dialer 124. A user 144 is a 
person operating the computer on which the dialer software 124 is running. 

Most of the components in the system 120 are analogous to components described 
previously with respect to Figs. 1-3. The dialer 124 connects to the network server 128 
through a modem rack, such as the modem rack 1 8 shown in Fig. 1 . The server 1 28 is 
identical to the communication server 22 described previously with respect to Fig. 1, and is 
commercially available from sources such as Cisco Systems Inc. (Cisco 2500™) and 
Ascend Communications (Ascend Max 4000™). The server 132 is analogous to the server 
14, but includes additional software described below. The server 140 is identical to the 
server 68. The hardware components of the servers 132, 136 and 140 are commercially 
available from sources such as SUN, DEC, IBM and HP. 

Comparing Fig. 5 to Fig. 3 illustrates that the system 120 includes the routing 
servers 136 and 138 which are not present in the system shown in Fig. 3. Fig. 6 illustrates 
the way the server 136 functions in the system 120. The user 144 connects to the system 
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120 via the dialer 124 and transmits login information as was described previously with 
respect to Fig. 4. At block 150, the network server 128 issues a request to authenticate the 
login information. At block 1 54, the server 1 32 determines whether or not the login 
information contains a "roaming" designation such as the @ character followed by 
5 additional user information. If roaming information is detected, the server 132 queries the 
login information to the routing server 136 as indicated by block 158. 

Block 162 indicates that the server 136 includes software that attempts to match the 
"roaming" login information with an entry in a log table in the server 136. If the server 136 
can make a match, then at block 166 the server 136 returns information to the server 132 

1 0 that includes an IP address for a server that has the domain name contained in the login 

information provided by the user 144. The server 132 then sends an authentication request 
containing the user's name and password to the server 140. The server 140 checks this 
information and at block 170, transmits a message to the server 132 either stating that the 
user 144 should be granted or denied Internet access. 

1 5 Block 1 74 indicates that if the server 1 36 cannot match the "roaming" login 

information, then a message is sent to the server 1 32 stating that Internet access should be 
denied to the user 144. 

In another situation, if no roaming information was detected at block 154, then at 
block 1 76, the server 132 processes the login information to determine if the user is a 

20 customer of the local ISP. The decision to accept or reject the user is then based solely on 
the user authentication information maintained by the local ISP. 
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Fig. 7 illustrates a roaming settlement system 200. The system 200 includes an 
authentication server 204, a routing server 208 and a central settlement server 212. In the 
preferred embodiment, the system 200 also includes an FTP/ Web server 216. In the 
preferred embodiment, the server 204 is an Internet server such as is commercially available 
5 from companies like HP, IBM, SUN and DEC. The servers 208 and 212 are Unix 

compatible servers such as are commercially available from SUN and other companies. 

The authentication server 204 includes all of the functions of the server 132 (shown 
in Fig. 5) and also includes a billing software module 220 which collects data about the 
identity of the user 144 and the amount of time the user 144 is connected to the Internet as 

10 is explained in more detail below. The server 204 is operated by a local Internet Service 
Provider (local ISP) with whom the user 144 does not have an account. As explained 
previously with respect to the server 132 shown in Figs. 5 and 6, the server 204 allows the 
user 144 to accesses the Internet through the system 63 operated by a local ISP (See Fig. 3). 
In the preferred embodiment, the billing software module 220 collects data about 

1 5 the transaction in which the user 144 accesses the Internet. This data is referred to as the 
RADIUS accounting records and includes information of the following type: 1 . user name; 
2. user domain; 3. start time; 4. local server 204 address; 5. home server 68 address; 6. 
session ID; 7. communications server 22 ID; 8. account delay time; 9. account session 
time; 10. status (always 0); 11. account status type; 12. start time (GMT); and 13. time 

20 zone. The RADIUS records are transmitted to the server 208 over the Internet, for example 
using Unix Datagram Protocol (UDP). 
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The routing server 208 includes all of the functions of the server 136 (shown in Fig. 
5) and also includes a roaming collection receiver software module 224, a roaming loader 
client software module 228 and an unprocessed file database 232. The software module 
224 receives the RADIUS records from the server 204 and stores them in the database 232. 
5 The database 232 comprises a directory on the hard drive of the server 208. A new file is 
created in the directory each time the user 144 connects to the Internet through the server 
204, a new file is created in the directory. The files comprise data derived from the 
RADIUS packets. The software module 224 may remove some fields from the RADIUS 
record or packet before it is stored in the database 232. For example, the number of octets 

1 0 may be reduced and/or the termination cause fields may be removed. 

Preferably, the module 220 attempts to send each RADIUS record to the module 
224 as soon as the record is created by the module 220. The module 220 continues 
attempting the transmission of the RADIUS record until an acknowledgment is received by 
the module 220 that the module 224 has received the transmission. The software module 

1 5 228 generates remote process calls (RPC) to the server 212 and sends the raw roaming data 
from the database 232 to the server 212. 

In the preferred embodiment, the server 208 is not located at the same physical 
location as the server 204. Rather, a purpose of the server 208 is to collect RADIUS 
records (or similar data) from a plurality of the servers 204 which are operated by many 

20 different local ISP's. Each server 204 would have a software module 220. For example, 
seventy-five different local ISP's in Japan, China, Taiwan and other countries could each 
have a server 204. A single server 208 could be located in Singapore for gathering the 
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RADIUS records (or similar data) from each of the seventy-five servers 204 operated by the 
local ISP's. 

The central settlement server 212 includes a roaming loader server software module 
240, a Filtering software module 244, a report software module 248, a roaming raw database 

5 252 and a roaming history database 256. The software module 240 receives daily requests 
from the software module 228 to transfer data from the database 232 to the server 212. 
When the data is received at the server 212, the module 240 causes the data to be stored in 
the database 252. The filtering software module 244 processes ("cleans") the data stored in 
the database 252 to put the data in a form that can be incorporated into reports. After data 

1 0 has been cleaned by the module 244, it is stored in the data base 256. 

Data is input into the roaming raw database 252 in a particular format. For 
example, in the preferred embodiment, each line of the input file is a record consisting of 
seventeen fields. The seventeen fields are: 1. user name; 2. user domain; 3. account 
status type; 4. account session ID; 5. account session time; 6. account delay time; 7. 

15 communications server 22 (NAS) identifier; 8. local AAS ID; 9. Home AAS ID; 10. stop 
time (GMT); 11. stop time (local); 12. time zone; 13. entry ID; 14. create date; 15. time 
put in roaming history database 256 (RHDB); 16. record status; and 17. pair status (refers 
to start/stop records). Preferrably, the software module 228 transforms the data from the 
database 232 into this format that will be input to the database 252 before the data is sent 

20 from the server 208 to the server 212. However, in other embodiments, the module 240 
could perform this function. 



AIMN-01-6 
291/01 1967I.0I/1 



12 



Data is outputted from the roaming raw database 252 in the same format as it was 
inputted and is processed ("cleaned") by the filtering software module 244. Data cleaning 
is required to remove duplicate records, remove irrelevant records and remove error 
records. Records relating to the same basic service type but different service sources may 
have slightly different record formats. The data cleaning operation also reformats non- 
conforming records into a normalized form for each basic service type. 

Duplicate records may result from low level protocols used in the initial data 
collection transmissions which send retry records whenever an acknowledgment of 
receipt is not received within a specified time. Multiple records are recognized as 
duplicates of the same usage occurrence by some number of record fields which define 
uniqueness within some time period. The time factor is a necessary consideration since 
identification fields have a limited length and so may reach their maximum values, and 
rollover to the initial value, within some time period. 

Irrelevant records may result from a richness in the record source beyond that 
required for usage measurement. These may be informational or error conditions not 
directly related to billable service usage. These records are not entered into the database 
256. 

After the data has been cleaned by the software module 244, it is stored in the 
roaming history database 256. In the preferred embodiment the databases 252 and 256 
are Oracle® databases. The server 212 is a SUN or SUN compatible (i.e. SPARC® 
microprocessor) server running the Solaris® operating system. Other types of servers, 
operating systems and databases could also be used in the present invention. 
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The report software module 248 takes data from the database 256 and uses it to 
generate settlement reports that describe the amount of time the user 144 was connected to 
the Internet through the system operated by the local ISP (i.e. by the local ISP who operates 
the server 204). Once the reports are generated by the module 248, they are stored in a local 
5 file system on the server 212. The reports are then transmitted to the server 2 1 6 by FTP. 

The reports generated by the module 248 also identify the home ISP for the user 144 
(i.e. the ISP who operates the server 140), so that the fees due for the usage of the Internet 
connection by the user 144 can be charged to the home ISP and credited to the local ISP. 
Normally, the usage data is also processed according to certain criteria to yield a monetary 
10 amount associated with the usage. For example, for each record in the database 256, a 
consumer rate and a provider rate is applied to the units of usage. From the 
multiplication of these rates over the usage units a monetary amount is determined. The 
rates may be structured as a single flat rate for all similar usage or as a variable rate based 
upon such factors as geographic location of the service usage, time or date of usage, 
1 5 identity of the service provider, identity of the service consumer and/or identity of the 
consumer's associated ISP. The monetary amounts are expressed in a single currency. 
Additionally, a charge is usually added to compensate the settlement operator (discussed 
below) for processing the accounts and/or providing other services related to the system 
200. 

20 In the preferred embodiment of the present invention, the funds due and/or owed to 

the various home and local ISP's are collected by a single entity, referred to as the 
settlement operator, that operates the servers 212, 208 and 216. The settlement operator 
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collects funds from all ISPs who owe monetary amounts as shown on their settlement 
reports. These amounts are due within a well defined time period. When received, these 
funds are deposited into a bank account where they are available for disbursement to ISPs 
who are owed monetary amounts as shown on their settlement reports. The 
5 disbursements are due within a well defined time period which is longer than the time 
given for payment due to the settlement operator. 

Two methodologies may be employed for disbursement of funds. The preferred 
methodology is to guarantee payments to ISPs who are due funds even though sufficient 
funds have not yet been received by related service consuming ISPs. Adequate cash flow 

10 to enable continuous operation by this method requires submission of adequate pre- 
payments or letters of credit by each potential service consumer to the settlement operator 
based upon expected usage levels. This method also requires periodic monitoring of 
debts incurred to ensure that adequate capital or credit is available. If not adequate, the 
prepayment or credit must be increased. If these are not secured, then service must be 

15 denied to the ISP. 

Another methodology is to withhold payments which are not adequately covered 
by amounts received and available in the disbursement account. At any given time each 
ISP may only be paid the aggregate amount received from those ISPs who consumed the 
services. As amounts due from service consumers are remitted, payments may be made. 

20 This methodology is more complicated and requires matching of related ISP accounts and 
amounts during the collection and disbursement process. It may also decrease confidence 
in the soundness of the settlement system by those who are owed funds. 
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On a regular periodic basis, settlement reports are generated by the software 
module 248 which document service usage between ISPs. The settlement operator 
provides four types of reports to each ISP participant: Detail, Summary, Invoice and 
Credit/Debit. Fig. 8 illustrates a Detail Report. A Detail Report shows service usage 
5 aggregated by user and contains other groupings to enable derivation of monetary 

amounts, such as the country . and telephone prefix, as appropriate. Fig. 9 illustrates a 
Summary Report. A Summary Report sums these usage units for each pair of ISPs. Fig. 
10 illustrates an Invoice Report. An Invoice Report converts the usage representations in 
the Summary Report to monetary amounts, e.g. minutes to dollars. There is one of these 

10 first three reports for each service consumed or provided by an ISP. Finally a 

Credit/Debit Report nets the credits and debits resulting from all the Invoice Reports and 
presents a consolidated statement of the amount due or owed to each other ISP and to the 
entire set of cooperating ISPs in total. Fig. 1 1 illustrates a Credit/Debit Report. 
Obviously, other types of reports can be prepared based on the information stored in the 

15 database 256. 

Referring to Fig. 8, each of the ISPs A-J would be a member of a group that has 
agreed to use the system 200 (GRIC members). Each of the ISPs A-J would operate at 
least one server 204. Fig. 8 illustrates that a user (userl@isp_b), who has an account 
with ISP B in country 2, accessed the Internet throught the system of ISP A in country 1 
20 twenty-eight times, for a total of 108 minutes during this billing period. A user 
(userl@isp_a), who has an account with ISP A in country 1, accessed the Internet 
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through the system of ISP C in country 3 two times, for a total of nine minutes during this 
billing period. Similar information for ISPs D-J appears in Fig. 8. 

Fig. 9 summarizes the information in Fig. 8. Fig. 10 converts the information 
from Fig. 9 into monetary amounts and also adds a monetary fee for use of the servers 
208, 212 and 216 (ARS Handle Fees) based on the total time connected to the Internet 
and the number of connections. Fig. 1 1 summarizes which charges are credits and which 
are debits for each ISP, and calculates a net amount due from or owed to the ISP. 
Generally, when a local ISP is providing Internet access to a user who has an account 
with a home ISP, the local ISP receives a credit, and the home ISP receives a debit (i.e. 
the home ISP owes money for the transaction, including the ARS handling fees, and the 
local ISP will be paid money for providing the Internet access). For example, Fig. 1 1 
shows that the settlement operator owes ISP A $5.54. The settlement operator will 
collect this amount from the ISPs who have debits that yielded this amount, along with 
the proper ARS handling fee. 

Example 1 below is an example of a detail transaction record in ASCII format. 
Generally, the detail transaction record would include additional similar entries for a 
plurality of other users who had utilized the particular ISP's service. 

Example 1 

H DT^ ,, RM^ ,, 07/10/97^ M 01:43::35^ ,, 06/30/97^ ,, 18:43:35^ * , userl@aimnet.com n , 
"Aimnet;USA M , M Connect.com;Australia' , , ,, S n , ,, 300 M 
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The entries in Example 1 have the following meanings: "DT" - means report type 

(i.e. detail transaction), "RM"- means service type (i.e. roaming), "07/10/97" and 

"01 :43::35" are the date and time the transaction terminated (in G r ecnioh Mean 

A 

Time);"06/30/97" and "18:43:35" are the date and time the transaction terminated (in 
5 local time), "userl@aimnet.com" and "Aimnet;USA" are the identifiers for the user 144 
and his or her home ISP, "Connect.com and Australia" are the identifier and country for 
the local ISP,"S" means units of time for the duration of the transaction (i.e. seconds), and 
"300" means the duration of the transaction (i.e. 300 seconds of Internet connection time). 
Once the settlement reports have been generated, they are made available to the 
10 home and local ISP's via mail, facsimile, e-mail, and/or the World Wide Web (HTML 
transmitted over HTTP). Other types of reports, such as the detail transaction record 
shown in Example 1 are sent to the local ISP's as an ASCII file 260 by the server 216 
using file transfer protocol (FTP). In the preferred embodiment, the server 216 is a 
combination world wide web (WWW) and FTP server which allows the settlement 
1 5 reports to be published on a web-page or sent by FTP. The servers 212 and 2 1 6 are 
preferably connected by an "intranet" operated by the settlement operator. 

Fig. 7 illustrates that in the preferred embodiment, the reports shown in Figs. 8, 9, 
10 and 1 1 are posted on a web page 264. The detail transaction record shown in Example 
1 is sent as the ASCII file 260. This allows the ISP to download the detail transaction 
20 records directly to a database 268 and to view and/or download the other reports directly 
at an accounting site 272. The database 268 is used, for example, to generate invoices for 
the users 144 who have accounts with the home ISP (i.e. for users who have used another 
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ISP to gain access to the Internet and now must pay their home ISP). Preferably the 
ASCII file 260 and web page 264 are secure (e.g. by password protection) so that only a 
designated ISP can view a specified report. 

. Generally, the servers 212 and 216 are located at a geographic location that is 
5 different than the location of the servers 208 and 204. Typically, several of the servers 
208 (e.g. 2-4) are in communication with one central settlement server 212. Of course, 
depending on the circumstances, the number of servers 208 could be increased or 
decreased. Furthermore, more than one server 212 could be utilized, although a single 
server 212 is the preferred number. As indicated in Fig. 7, in the preferred embodiment 

10 the server 204 is located at the ISPs' premises, along with the billing database 268 and 
the accounting site 272. When a report is published by the server 216, it is usually 
transmitted to, or made available to, the accounting site 272 and/or the database 268 
located at both the home ISP and the local ISP. The home ISP needs the reports so that 
billing to the user 144 can be generated. The local ISP needs the reports so that the 

1 5 amount of money or credit owed to the local ISP can be tracked. 

Use of the system 200 is not limited to use with Internet roaming technology. 
Rather, it can also be used to provide accounting information for other Internet services 
such as Internet faxing or Internet phone calls. The generalized steps in the process are: 
using a first server to track an amount of time a first user is connected to the Internet 

20 through a first system operated by a first Internet Service Provider with whom the first user 
does not have an account (for Internet roaming) or the amount of time for some other 
service (like faxing, phone call, etc.); transmitting a user record from the first server to a 
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central settlement server, the user record comprising data that includes an identifier for the 
first user and the amount of time the first user was connected to the Internet through the first 
system; and using the central settlement server to generate a report from the user record, the 
report including at least the amount of time the first user was connected to the Internet 
5 through the first system. Of course the user record can be routed through a second server as 
described previously with respect to the server 208. If the server 208 is not used, some or 
all of the functions of the server 208 can be incorporated into the server 204. 

Although the present invention has been described in terms of the presently 
preferred embodiment, it is to be understood that such disclosure is not to be interpreted as 
10 limiting. Various alterations and modifications will no doubt become apparent to those 
skilled in the art after having read the above disclosure. Accordingly, it is intended that the 
appended claims be interpreted as covering all alterations and modifications as fall within 
the true spirit and scope of the invention. 
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